---
title: Conditions
subtitle: Set conditions for when events or instruments are triggered
description: Set conditions for when events or instruments are triggered in the Apollo GraphOS Router.
context:
  - telemetry
redirectFrom:
  - /graphos/routing/observability/telemetry/instrumentation/conditions
---

You can set conditions for when an [instrument](/router/configuration/telemetry/instrumentation/instruments) should be mutated or an [event](/router/configuration/telemetry/instrumentation/events) should be triggered.


## Condition configuration
Here is an example of a condition on a custom instrument:

```yaml title="router.yaml"
telemetry:
  instrumentation:
    instruments:
      router:
        my.instrument:
          value: duration
          type: counter
          unit: s
          description: "my description"
          # ...
          # This instrument will only be mutated if the condition evaluates to true
          condition:
            all:
              - any:
                  - eq:
                      - "val"
                      - request_header: x-req-header
              - eq:
                  - "foo"
                  - response_header: x-resp-header
```

#### `exists`

The `exists` condition is testing if [selectors](/router/configuration/telemetry/instrumentation/selectors) is present.

For example, the following condition checks the value of `x-req-header` exists:

```yaml
exists:
  request_header: x-req-header
```

#### `eq`

The `eq` condition is an equality test between [selectors](/router/configuration/telemetry/instrumentation/selectors) or values.

For example, the following condition checks the value of `x-req-header` is equal to `val`:

```yaml
eq:
  - "val"
  - request_header: x-req-header
```

You can use selectors on both sides of the equality test:

```yaml
eq:
  - request_header: x-req-header1
  - request_header: x-req-header2
```

Values may be of types `string`, `number` or `boolean`.

#### `gt`

The `gt` condition checks that one value is greater than another.

For example, the following condition checks the response status code is greater than 299:

```yaml
gt:
  - response_status: code
  - 299
```

Values may be of types `string`, `number` or `boolean`.

#### `lt`

The `lt` condition checks that one value is less than another.

For example, the following condition checks the response status code is less than 500:

```yaml
lt:
  - response_status: code
  - 500
```

Values may be of types `string`, `number` or `boolean`.

#### `not`

The `not` condition is a negation of the nested condition.

For example, the following condition checks the value of `x-req-header` is _not_ equal to `val1`:

```yaml
not:
  eq:
    - "val1"
    - request_header: x-req-header2
```

#### `all`

The `all` condition is a list of conditions that all must be true in order for the condition to be true.

For example, the following `all` condition has a list of `eq` conditions that check the values of `x-req-header1` and `x-req-header2`, and both `eq` conditions must be true in order for the `all` condition to be true:

```yaml
all:
  - eq:
      - "val1"
      - request_header: x-req-header1
  - eq:
      - "val2"
      - request_header: x-req-header2
```

#### `any`

The `any` condition is a list of conditions of which at least one must be true for the condition to be true.

For example, the following `any` condition has a list of `eq` conditions that check the values of `x-req-header1` and `x-req-header2`, and at least one of the `eq` conditions must be true in order for the `all` condition to be true:

```yaml
any:
  - eq:
      - "val2"
      - request_header: x-req-header1
  - eq:
      - "val2"
      - request_header: x-req-header2
```

### Condition configuration reference

The available basic conditions:

| Condition | Description                                             |
|----------|----------------------------------------------------------|
| `eq`     | An equality test between selectors or values             |
| `gt`     | An inequality test between selectors or values           |
| `lt`     | An inequality test between selectors or values           |
| `exists`  | A check to see if the selectors value exists             |
| `not`    | A negated equality test between selectors or values      |
| `all`    | A list of conditions that must all be true               |
| `any`    | A list of conditions of which at least one must be true  |

You can create complex conditions by using these basic conditions as building blocks.

## Example condition configurations

Some example configuration of common use cases for conditions.

### Event for a specific subgraph

You can trigger an event for a specific subgraph by configuring a condition with the subgraph's name. 

The example below uses the [`subgraph_name`](/router/configuration/telemetry/instrumentation/selectors#subgraph) selector to log subgraph responses for the subgraph named "products":

```yaml title=router.yaml
telemetry:
  instrumentation:
    events:
      subgraph:
        response:
          level: info
          condition:
            eq:
            - subgraph_name: true
            - "products"
```

### On GraphQL error

You can use the [`on_graphql_error`](/router/configuration/telemetry/instrumentation/selectors#supergraph) selector to create a condition based on whether or not a GraphQL error is present.

The example configuration below uses `on_graphql_error` to log only supergraph responses that contain GraphQL errors:

```yaml title="router.yaml"
telemetry:
  instrumentation:
    events:
      router:
        request:
          level: info
          condition: # Only log the router request if you sent `x-log-request` with the value `enabled`
            eq:
            - request_header: x-log-request
            - "enabled"
        response: off
        error: error
      supergraph:
        response:
          level: info
          condition: # Only log supergraph response containing GraphQL errors
            eq:
            - on_graphql_error: true
            - true
        error: error
```

### On large payloads

For observability of large payloads, you can set attributes using conditions that indicate whether the length of a request or response exceeds a threshold.

The example below sets a custom attribute to `true` if the length of a request is greater than 100:

```yaml
telemetry:
  instrumentation:
    spans:
      mode: spec_compliant
      router:
        attributes:
          trace_id: true
          payload_is_to_big: # Set this attribute to true if the value of content-length header is > than 100
            static: true
            condition:
              gt:
              - request_header: "content-length"
              - 100
```
